home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5095 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.8 KB
  1. Path: ob1.uws.edu.au!news
  2. From: Russell Sayers <rsayers@st.nepean.uws.edu.au>
  3. Newsgroups: comp.lang.c
  4. Subject: Concurrent file access ??
  5. Date: Thu, 08 Feb 1996 11:26:24 +1100
  6. Organization: University of Western Sydney
  7. Message-ID: <31194330.21FF9711@st.nepean.uws.edu.au>
  8. NNTP-Posting-Host: 137.154.130.88
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset=us-ascii
  11. Content-Transfer-Encoding: 7bit
  12. X-Mailer: Mozilla 2.0b6a (X11; I; Linux 1.3.53 i486)
  13.  
  14. I'm currently trying to write a CGI trivia program on my UNIX account at
  15. universty.  The program currently consists of a whole load of functions
  16. that open a file, do what they have to do, then close the file.  These
  17. functions do things like select a random question entry from a data
  18. file, then display it in HTML format, or read in a "users" score from
  19. another data file.
  20.  
  21. I've noticed that when a function is called within a few lines of the
  22. last call then it gives bad results.  I guessed this was some sort of
  23. latancy in the open file table.  So I put a "sleep(1)" after each time a
  24. file was closed.  This was still not enough for some functions.  Some
  25. required a "sleep(3)" or higher to get a correct result.  Though they
  26. all work when given enough time between file opening and closing, this
  27. is slowing down my program TOO much!
  28.  
  29. When a C program of mine has a file opened, I've noticed that in another
  30. shell the file appear tuncated.  Is this something that I cannot work
  31. around??  How come editors like PICO can have the same file open in two
  32. sessions?  I'm guessing than PICO rapidly reads in the data, then closes
  33. the file.  Even if I can over come this latency this program will most
  34. probably be running concurrently by several users, am I going to have to
  35. observe "critical sections".
  36.  
  37. I'd REALLY appreciate the help,
  38.  
  39. Russ
  40. (rsayers@st.nepean.uws.edu.au)
  41.